Integrated circuit (IC) design and development is presently a very difficult and expensive process. An ever-widening design gap is appearing as the stringent constraints of today's ASIC (Application Specific Integrated Circuit) methodologies and EDA (Electronic Design Automation) tools are causing designers to fail at effectively using all the extra gates that each new fabrication technology offers.
Full custom design has become extremely expensive, even when those designs result in massively regular structures, such as cache memory, because the exponentially increasing complexity in the low-level details of each new fabrication technology do not allow much new design in the available time. IC speeds are being limited by present day architectures, which have an ever increasing need for long wires and more and more interconnections between chip components. This increased amount of interconnection is causing a new manufacturing paradigm where defects in the wiring dominate.
As fabrication technology continues to advance to transistor densities near one billion transistors on a single die, it is becoming apparent that the steeply rising design costs, exponentially increasing verification effort, inherent limitations of present day design tools, and the inability to effectively re-use what has gone before will make future development extremely expensive and only available to few.
Illustrated in FIGS. 1A and 1B is an example process to create an IC using ASICs and FPGAs (Field Programmable Gate Array). The design begins by creating a system model, illustrated here as interconnected functions As, Bs, and Cs. The system model can be modeled in any manner; such a modeling system includes, for example, a block diagram, a Unified Modeling Language (UML) model or a data flow graph. Once the system model is finished, a software description is created by hand, which is both time-consuming and is difficult to check. The software description may be created in, for example, C, C++, Java, Matlab, Smalltalk or System C. Next the software description is hand translated in to a Register Transfer Level (RTL) description that can be used to create a logic gate model of the system. RTL is a generic term for Hardware Description Languages (HDL), such as Verilog or VHDL, which can be used to generate the logic gate model through synthesis. RTL is used to create both ASIC (FIG. 1A) or FPGA (FIG. 1B) solutions. Again, translating from the software description to RTL by hand is both time-consuming and difficult to check. For an ASIC, once synthesis has created the logic gate model, more software is used to place and route the functional gates, using semi-automated hardware layout tools. Once laid out, the generated patterns are optimized to account for optical effects in the manufacturing process. It should be noted that there are many iterations needed to optimize the process, and some of the optimizations are manually performed. Finally, a mask set is created and used to make the particular designed ASIC.
With reference to FIG. 1B, similar processes occur for creating an FPGA. Again an RTL description and synthesis is used to develop the logic gate model. Several iterations may be required to ensure the design physically fits onto the target part. Once the mapping is known, the design is tested to ensure the timing requirements are met. If the timing design requirements are not initially met, the structure of the RTL must be altered until both the mapping and the timing requirements are satisfied. For example, it is quite often necessary to have multiple repetitions of the same logic which run in parallel to ensure the timing constraints can be met; this can only be accomplished by altering the RTL description. Finally, the logic mapping for every element on the FPGA is loaded into a ROM. When the FPGA device is powered on, all the FPGA elements are automatically loaded from the ROM to create the desired function.
Because of the shrinking size of transistors and other IC components, full-custom design will require many more designers than are used at the present, which adds huge complexity and requires exponentially more time and resources to develop compared to the present state of the art. In an attempt to reduce the hardware complexity and reduce the verification risk of making a mistake in the hardware, many systems are now using a mixture of hardware and software. In this new paradigm, performance is traded-off against using software running on programmable hardware for many of the components so that functionality and bugs can be fixed after the device has been manufactured. This co-design process, where software and hardware co-exist to create the solution, is a problem that has been explored extensively in the last twenty years with little success.
Extensive re-use of hardware and software components, essential to ensuring that large, complex designs can be executed and verified within a reasonable time, has proven to be unachievable and has only been managed in a limited sense within small, tightly-knit design centers.
Embodiments of the invention address these and other limitations in the prior art.